The state of the art for digital content inhibits content sharing. Content sharing is beset with convolutions. File transformations are imperative. Indirect link sharing via social networks and commenting on content thereof is a multi-billion dollar enterprise. Direct link sharing works well until a link rot takes over. To perpetuate connectivity with their customers, namely, users of user devices, businesses and institutions use a cloud computing environment for content delivery, which is not desired by some users. With no hypertext markup language (HTML) file available to readily download, users have to install other applications or plugins that are often proprietary for local storage of content. The users often buy devices to consume the content that they have paid for, which gives gatekeepers of content, for example, online stores selling the content, greater control over the content than producers of the content. Authors and publishers find it difficult to go independent of the gatekeepers of the content, because publishing requires professional assistance, and a lot of marketing is required to make a published product discoverable. Publishers have to publish in different formats, for example, a webpage format, an electronic book (eBook) format for multiple applications and devices, a print format, etc., and make all the formats and the related content discoverable. Even as overheads of publishing are increasing, profit margins are declining. Hence, authors and publishers have to conform to gatekeepers for delivery of the content.
The internet, the world wide web consortium (W3C), and the Unicode Consortium together allow an alternate business method for content delivery. Hypertext markup language (HTML) has been around for some time and is evolving. HTML, together with the Unicode® standard of Unicode Inc., and the W3C® standards of Massachusetts Institute of Technology, is an open content standard. HTML is a rich content container with cross-media support. Hypertext markup language 5 (HTML5) is the fifth revision of the HTML standard. HTML5 documents are typically served through a hypertext transfer protocol (http) address or a hypertext transfer protocol secure (https) address from a remote server with a persistent internet connection. Webpages are typically cached by a browser so that even if internet connectivity is lost, the webpages are not lost, as long as the browser remains open. Recent HTML5 initiatives have made it possible to store cached content in the browser, so that the content can be recovered if the same uniform resource locator (URL) is opened again in the browser after closing the browser even without any internet connectivity. Storage of the cached content in the browser also helps in the fast reloading of the HTML pages.
However, a continuing problem with webpages with the hypertext transfer protocol (http) addresses or the hypertext transfer protocol secure (https) addresses is that the user is dependent on a server implementation for reloading the content and it is possible that the same content is no longer available again in the same uniform resource locator (URL). The standard user behavior in this changing http or https landscape is to download the content in a format that the user can download, for example, in a portable document format (PDF), to a local hard disk on a user device for later use. An impediment to using the hypertext markup language (HTML) for portable files is that an HTML file or an HTML page cannot be downloaded to local storage in an HTML format. HTML content can only be shared as a link to allow persons with whom the HTML content is shared to access the HTML content from a cloud computing environment. Currently, browsers only support saving a webpage as a non-standard web archive. Some browsers allow webpage downloads through plugins. Although HTML5 as a document format has many capabilities, the lack of consistency in its implementation and the lack of portability make users tend to prefer the PDF.
Publishing is moving from circulation and readership metrics to engagement metrics, where engagement with readers of published content is considered. This is because engagement equates revenue, not only for publishers, but also for researchers and authors. To authors who are looking to find their next grant, engagement with their community and the extent of engagement means the next grant. Multi-channel content delivery covering the hypertext markup language (HTML) format, a portable document (PDF) format, an electronic publication (ePub) format, and applications, among others, has advanced in recent times as the primary mode of engagement, the rationale being that the readers are attracted one way or the other. There are inherent problems with this mode of multi-channel engagement. Firstly, multi-channel delivery places multiple production and distribution overheads on publishers and affects speed to market the content. Secondly, a file format like the PDF is more a means of disengagement than engagement. When a PDF file is available to download, readers download the PDF file to a user device and are disengaged thereafter. It is difficult or, in some cases, not possible for publishers to find out what the readers do with the PDF file and when. The scenario of engagement with the readers is the same with an ePub file, where the readers get disengaged after obtaining the ePub file, unless there is an application on the user device that opens this ePub file, which can then send information about engagement of the reader with the ePub file back to the publishers, which is circuitous. Therefore, there is a need for a method that collects information about engagement of the reader with a file in a portable format stored locally on a user device, such as read metrics, through engagement with a publisher every time the file is opened, and for as long as the file is in use. Moreover, should a user, for example, a reader, make and distribute copies of the file, such copies of the file cannot be tracked using conventional methods. Therefore, there is a need for delivering a file for download purposes with codesets embedded in the file for homing, where homing is the ability of the file to stay connected with a server from where the file is delivered, and transmit file-level activity, for example, making copies of the file, to the server. In the absence of homing, a file will have to be encrypted to prevent unintended use.
Continuing engagement requires that touchpoints, that is, information about engagement of users of the file, including authors and readers, in the local files on the user devices, be read continuously and indexed for establishing communication between the users, and compiling usage information associated with usage of the file for conveyance to publishers, the authors, and researchers. Indexing is typically based on keywords and/or metadata, which limits the discoverability of content, due to which search engines end up pulling a lot of irrelevant information. Content is often rendered with forms to fill, buttons to push, hyperlinks to click on, etc., to a machine on which users interact with a file with the content. The machine's understanding of user interaction is limited to the interactions of users with the forms, buttons, hyperlinks, etc. When users interact with the content in the file instead of interacting with the forms, the buttons, the hyperlinks, etc., in the file, there is a need for recording each content unit of interaction against a title and metadata of the file that is already available, thereby constantly raising levels of the machine's awareness and setting up search engines for more meaningful content discovery. Moreover, recording each content unit of interaction against the title and the metadata of the file facilitates search engines that are built around machine learning to learn better.
The information about the engagement of the users with the local files on the user devices needs to be conveyed to a server through a network, for example, the internet, to compile the usage information. Browsers used to access a file, for example, a hypertext markup language (HTML) file, on a network, for example, the internet, restrict communication between a local file on a user device and the server, for example, by restricting local files from cross-site scripting using asynchronous JavaScript and extensible markup language (XML) (AJAX) calls, to prevent security threats, where AJAX is a set of web development techniques. There is a need to circumvent such restrictions to send information about the engagement of the users with the local files on the user devices to the server for compiling the usage information. Moreover, there is a need for collecting information about the engagement of the users with the local files on the user devices even in instances of a loss of connectivity of the user devices with the network through which the collected information is sent to the server for establishing a communication between the users and compiling the usage information. Communication between the users of the file allows engagement of publishers and authors with readers of the file. There is a need for establishing communication between the users of the file to create a content-centric social network of the users of the file.
Current social media paradigms demand a great deal of effort on the part of users to form a group. On social platforms, users having common interests are not easily located, and locating them involves a lengthy process of discovery. The process of discovery entails random broadcasts to obtain the attention of potential group members. The random broadcast is susceptible to attacks, and may be viewed as boastful, narcissistic, impertinent, etc. There is a need for making the process of discovery of potential group members easy and automatic to avoid attacks from strangers in the network. Moreover, current social media engines impose restrictions on the extent of content that can be posted, tweeted, pinned, etc. There are word limits, image limits, media-size limits, etc., and therefore, electronic mail (email) and file sharing, which have less social involvement, continue to be primary vehicles for sharing unabridged content. Where there is no restriction on content type or length, for example, in blogs, websites, etc., the authoring environment often requires the user to have substantial skills in web technologies, for example, hypertext markup language (HTML), cascading style sheets (CSS), JavaScript®, etc., and server-side technologies, for example, hypertext preprocessor (PHP).
Hence, there is a long felt need for a computer implemented method and a computer implemented system that transform a content file into a content-centric social network with managed connectivity and indexable touchpoints. Moreover, there is a need for a computer implemented method and a computer implemented system that compile usage information associated with usage of one or more portable local copies of a content file on one or more user devices. Furthermore, there is a need for a computer implemented method and a computer implemented system that deliver a content file for download purposes with codesets embedded in the content file for homing. Furthermore, there is a need for a computer implemented method and a computer implemented system that circumvent restrictions placed by browsers on the user devices to send information about engagement of users of the content file with the portable local copies of the content file on the user devices to a server for compiling the usage information. Furthermore, there is a need for a computer implemented method and a computer implemented system that collect the information about the engagement of the users with the portable local copies of the content file on the user devices even when connectivity to the network is lost, and send the collected information to the server when connectivity to the network is reestablished. Furthermore, there is a need for a computer implemented method and a computer implemented system that group users based on common interests and context of the content files to form the content-centric social network automatically.